home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98a.txt
/
000135_icon-group-sender _Mon Mar 16 08:02:43 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
4KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id IAA19545
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 16 Mar 1998 08:02:42 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA18571; Mon, 16 Mar 1998 08:02:42 -0700
Message-Id: <199803151331.GAA18413@orpheus.gemini.edu>
From: swampler@noao.edu (Steve Wampler)
Date: Sun, 15 Mar 1998 06:31:19 MST
In-Reply-To: Mark Evans's mail message of Mar 13, 4:06pm.
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: icon-group@optima.CS.Arizona.EDU
Subject: Re: Letter Probabilities
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 2816
On Mar 13 at 4:06pm, Mark Evans writes:
} To the group -
}
} The probability table is simply a requirement for output. As long as
} I'm going to compute it anyway, it's useful. When you generate 'random'
} text without computing it, there is no way to tell from the output what
} are relative probabilities except by very, very gross estimation. The
} table tells you in a glance, top to bottom.
The table may be useful for seeing the relative probabilities, which is
useful for checking for anomolies. (If you produced 'random' text based
on the novel "Gadsby" for example, the table would help explain the
strange output you'd get.)
It is not all that useful in actually generating the 'random' text,
however - the problem becomes much harder when using it! (See the
aside below)
Why not generate the table as an aside and keep the 'random' text
generation simple? If you think about it, the 'generated string'
solutions that are proposed work on the *same* principle as you
want to use with your table, but without having to convert the
information embedded in the input stream into numeric values and
then back again and without having to convert probability values
into unique numeric ranges.
(As an aside, if the table really contains the 'relative probabilities'
of the characters then it is *very* hard to use it to produce the
'random' output text correctly! The table has to contain not the
relative probability, but a unique numeric range whose proportion to
the total range matches the relative probability. So, 'at a glance',
it would not show the relative probability anyway.)
} Actually my little program has grown into a moderately complicated Icon
} case study. I've bumped against the 32K limit, that's for sure. It has
} buttons, menus, all kinds of things going on.
32K limit? This is news to me - what version of Icon and what platform
are you using? I'm sure you can bump that *way* up with most machines
these days!
} No one has really answered my original question about the inner while
} loop. Whether it is ideal for this problem or not, I would like to know
} whether Icon has some elegant mechanism for scanning such an ordered
} list.
I've lost your original message and so can't be specific, but here's
an approach to a similar problem:
Let 'a' be an ordered list of floating point values, high to low, between
0.0 and 1.0.
Let 'x' be a value between 0.0 and 1.0.
The following code assigns to i the index of the first value in 'a' that
is <= 'x':
x > a[i := seq()]
Again, note that this (and any similar approach) does not do what you
want if the values in 'a' are relative probabilities.
--
Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
The gods that smiled at your birth are now laughing openly. (Fortune Cookie)